133. The microcontroller of Claim 132 wherein the security protocol requires that a / 
particular identity must be validated to permit loading a derivative program onto/a 
card. / 

134. The microcontroller of Claim 132 further comprising a decrypjidn key wherein 
the security protocol requires that a derivative program to be leaded is encrypted 
using a loading key corresponding to the decryption key^/ 

135. The microcontroller of Claim 127 wherein the microcontroller is configured to 
provide cryptographic services selected fromrfie set including encryption, decryption, 
signing, signature verification, mutual authentication, transport keys, and session 
keys. / 

136. The microcontroller of Claina 127 further comprising a file system and wherein 
the microcontroller is configured to provide secure access to the file system through a 
means selected from the set/including: 

(a) the microcontrollei/having access control lists for authorizing reading from a file, 
writing to a fileyor deletion of a file, 

(b) the microcontroller enforcing key validation to establish the authorized access to a 
file, and / 

(c) the microcontroller verifying card holder identity to establish the authorized 
access to a file.-- 

REMARKS 

This Amendment is intended to be a complete response to the Office Action of 
October 4, 1999, and the case is believed to be in condition for allowance. Accordingly, 
reconsideration is respectfully requested. 
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Changes to Specification: 

A number of minor typographical errors have been discovered upon review of the 
Specification. The above amendment to the Specification corrects those errors. No new 
matter has been added. 

Correction to Drawing: 

Enclosed is a replacement sheet for sheet 4 of the drawings. Elements 46, 47, 48, 
and 49 were previously numbered incorrectly. However, the discussion of these elements 
on Page 1 of the English language of the Specification makes it clear that the intended 
numbering should be as on the replacement drawing sheet. 

Also enclosed are replacement sheets for Figures 16 and 18 with corrections in 
red. In both instances the arrow leading into element 166 incorrectly originated with 
element 165 rather than element 164. Again, the proper flow through the algorithm is 
evident from the Specification. 

Status of the Claims 

Claims 1-105 are pending in the Application. Claims 1-105 were rejected in the 
Office Action. Claims 1, 6, 31, 36, 58, 91, 93, 95, 103, 104, and 105 are amended herein. 
Claims 106 through 136 are added herein. Claims 59 through 90 are cancelled herein 
without prejudice. 

The Claims 

35 USC 102 and 35 USC 103 

Claims 1-28, 31-97, and 100-105 were rejected under 35 USC 102(e) as being 
anticipated by Peyret et al. (U.S. Patent Number 5,923,884, hereafter "Peyret") and 
Claims 29, 30, 97, and 98 were rejected under 35 USC 103(a) as being unpatentable over 
Peyret et al. (U.S. Patent Number 5,923,884) as applied to claims 1 and 59, and further in 
view of Martineau (U.S. Patent No. 5,915,226). Applicants traverse these rejections. 
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It is well-established law that a reference does not anticipate a claimed invention 
unless each element of the claim is taught by the reference. See e.g., General Electric Co. 
v. Nintendo Co. (CA FC) 50 USPQ2d 1910 ("A judgment of invalidity for anticipation 
requires that a single prior art reference disclose every limitation in a patent claim"); 
PPG Indus., Inc. v. Guardian Indus. Corp., 75 F.3d 1558, 1566, 37 USPQ2d 1618, 1624 
(Fed. Cir. 1996) ("To anticipate a claim, a reference must disclose every element of the 
challenged claim and enable one skilled in the art to make the anticipating subject 
matter."). 

Claim 1 is amended herein to more clearly claim the subject matter of the 
invention. As amended, Claim 1 recites, for example, "a memory storing: an application 
derived from a program written in a high level programming language format, and an 
interpreter operable to interpret such an application derived from a program written in a 
high level programming language format". Peyret does not teach either of those 
elements. 

In the Office Action, which of course was directed to Claim 1 prior to the 
amendments herein, the Examiner indicated that Peyret teaches a memory storing an 
application having a high level programming language format. In doing so, the Examiner 
pointed to Peyret's disclosure in fig. 1 and in the abstract of the use of applets, 
erroneously inferring that Peyret was referring to the Java programming language. 
Applets does not imply Java. See for example, U.S. Patent No. 5,548,745, to Egan et al., 
filed January 19, 1993: 

Window application products such as Microsoft Excel for Windows® are 
known as a software application for performing and processing tasks by jumping 
between user selected application programs (hereinafter "applet"). Each applet is 
an independent function, such as an input function or an output function, and 
collectively the applets permit the operator to perform a specific task. 
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There are at least two types of applets: a container- type applet or an 
editor-type applet. Container applets represent containers in which data or other 
containers are to be held. For example, a container applet such as a "file cabinet' 1 
is a type of container ordinarily at the top of the hierarchy of containers. A file 
cabinet contains folders, messages, and data objects, each of which is also a 
container. A container applet could also be a folder, which may be a general 
folder or a mailbox folder. A container applet may also be a message wherein the 
message may be a facsimile message, phone message, modem message or an E- 
mail message. All of the above folders and messages may be contained in the file 
cabinet container. 

Applicants request that the Examiner take official notice that Window application 
products such as Microsoft Excel did not interpret Java in January 1993. Thus, there is 
no implication that Peyret was disclosing Java or any other high level language. 

Furthermore, there is a difference between an applet and an application. The 
word applet merely means small application. Usually an applet is a program designed to 
run in a specific environment, in the case of a Java applet, inside a Java-enabled web 
browser or, as discussed above in the quote from U.S. Patent No. 5,548,745, in the Excel 
program. 

Therefore, Peyret does not anticipate Claim 1. 

Furthermore, Claim 1 is not obvious over Peyret. As noted above, Peyret does 
not suggest, "a memory storing: an application derived from a program written in a high 
level programming language format, and an interpreter operable to interpret such an 
application derived from a program written in a high level programming language 
format" (Claim 1). Applicants do not agree with the inference that "applet" implies the 
use of a high level language. However, even if that inference is drawn, for the sake of 
argument, Claim 1 is nevertheless not obvious from Peyret. 
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It is well-established law that to render a claim obvious, a prior art reference must 
provide an enabling disclosure. Rockwell Intl v United States, 47 USPQ2d 1027, 1032 
(CAFC 1998), Motorola, Inc. v. Interdigital Technology Corp. 43 USPQ2d 1481, 1489 
(CAFC 1997), Beckman Instruments, Inc. v. LKB Produkter AB, 13 USPQ2d 1301, 1304 
(CAFC 1989). Peyret is completely silent on how to enable a program written in a high 
level language to operate on an integrated circuit card. Thus, Claim 1 is not obvious over 
Peyret. 

To put Java (or any other high level language) on an integrated circuit card is 
anything but obvious. At the time of the invention, the typical Java Virtual Machine 
required over 1 MB of memory. Any person of ordinary skill would realize that to 
squeeze such an interpreter into an integrated circuit card (such as a smart card) is 
anything but an obvious task. Applicants direct the Examiner to the following statement 
made about the author of a recent JAVA WORLD article 
(http://www.javaworld.com/javaworld/jw-04-1998/jw-04-ringfever.html): 

"About the author: Chuck McManis wrote the very first Crypto toolkit in Java 
when he was a member of the Java development group in 1993. He also brought 
in the first smart cards (Hitachi) at FirstPerson but gave up trying to put 
Java on them. (Now he knows better!) Today he writes columns and articles for 
JavaWorld and is currently holding the position of director of systems software at 
FreeGate Corporation in Sunnyvale." 

Applicants submit that Chuck McManis is well beyond a person of ordinary skill in the 
art of Java programming. In fact, he is a leading expert in the field of software design 
and holds at least four patents for his work. The fact that he "gave up trying to put Java 
on [smart cards]" is indicative of the non-obviousness of doing so. 

Applicants also invite the Examiner to consider the following excerpt including a 
quote from Scott McNealy (CEO of Sun Microsystems, the company that originally 
developed the Java language): 

"Like Playing Golf in a Phone Booth" 
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A smart card enabled by Java Card technology, dubbed the "world's thinnest 
computer," places the Java platform inside the .8 millimeter thickness of the 
plastic card, thus making it a small but integral part of a larger enterprise 
information system. 

Its creation was no small feat. "Fitting Java technology inside smart cards was 
like playing golf inside a telephone booth," remarks Sun CEO Scott McNealy. 

http://softwarema.usec.sun.com/features/1999/01/javacard.html 
JAVA CARDTM TECHNOLOGY GROWS UP SMART 
by Janice J. Heiss and John Papageorge 

When two experts in the field of the Java programming language consider putting 
Java on smart cards very difficult, for a person of ordinary skill it would certainly be 
unattainable. Peyret's disclosure, which neither mentions nor suggests high level 
languages nor how to put such language interpreters on a smart card, would be of no help 
to the ordinarily skilled person. 

For all these reasons, Claim 1 is neither anticipated by, nor obvious over Peyret 
and should be allowed. 

The Examiner rejected Claims 29, 30, 97 and 98 under 35 USC 103(a) as 
unpatentable over Peyret in view of U.S. Patent No. 5,9144,226 to Martineau (hereinafter 
Martineau). The Examiner relied on Martineau for a teaching of providing 
communications to a remote location. Martineau does not teach or suggest "a memory 
storing: an application derived from a program written in a high level programming 
language format, and an interpreter operable to interpret such an application derived from 
a program written in a high level programming language format" (Claim 1). Therefore, 
Claim 1 is patentable over Martineau, whether taken singly or in combination with Peyret 
and should be allowed. 

The argument above with respect to Claim 1 is applicable to all other independent 
claims in the application. For the reasons given above in support of Claim 1, all the 
independent claims are patentable over Peyret and Martineau taken singly or in 
combination. Accordingly, the independent claims should all be allowed. 
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The dependent claims all depend from an allowable independent base claim, 
incorporate all the limitations of their respective base claims, and provide further unique 
combinations. Therefore, each dependent claim is patentable for the reasons given above 
in support of Claim 1 as applied to such independent base claim and by virtue of such 
further unique combinations. Accordingly, applicants request reconsideration of the 
dependent claims and their allowance. 



It is submitted that all the claims now in the application are allowable. Applicants 
respectfully request reconsideration of the application and claims and its early allowance. 
If the Examiner believes that the prosecution of the application would be facilitated by a 
telephonic interview, Applicants invite the Examiner to contact the undersigned at the 
number given below. 

It is believed that no additional fees, other than the fee for the Petition for 
Extension of Time, are due in connection with this Response as has been indicated on the 
transmittal letter. If Applicant is in error as to these fees, the Commissioner is hereby 
authorized to charge any fees which may be required, or credit any overpayment, to 
Deposit Account 19-0597. 



Enclosures: 

1 . Acknowledgment Postcard 

2. Transmittal Form (1 sheet) 

3. Amendment Transmittal Letter (1 sheet) 

4. Petition for Extension of Time (1 sheet) & duplicate copy 

5. Submission of Drawing Amendment Form (1 sheet) 

6. Figs. 4, 16, & 18 with corrections marked in red ink (3 sheets) 



CONCLUSION 



Respectfully Submitted, 




Pehr B. Jansson 
Registration No. 35,759 
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Pehr B. Jansson 

Schlumberger Austin Product Center 
831 1 North FM 620, P.O. Box 200015 
Austin, TX 78720-0015 
Tel: 512-331-3748 
Fax:512-331-3060 
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